Hi @tjuyuxinzhang, this is an interesting situation. I see version 0.6.4 mentioned as fixed in https://rubysec.com/advisories/CVE-2015-1828/ and https://github.com/rubysec/ruby-advisory-db/blob/master/gems/http/CVE-2015-1828.yml, but 0.6.4 isn't mentioned at all in the original vendor disclosure (https://groups.google.com/g/httprb/c/jkb4oxwZjkU) or in ruby/openssl#8. How did you determine that 0.6.4 contains a patch?

Hi @tjuyuxinzhang, this is an interesting situation. I see version 0.6.4 mentioned as fixed in https://rubysec.com/advisories/CVE-2015-1828/ and https://github.com/rubysec/ruby-advisory-db/blob/master/gems/http/CVE-2015-1828.yml, but 0.6.4 isn't mentioned at all in the original vendor disclosure (https://groups.google.com/g/httprb/c/jkb4oxwZjkU) or in ruby/openssl#8. How did you determine that 0.6.4 contains a patch?你好，这是个有趣的情况。我看到 0.6.4 版本在 https://rubysec.com/advisories/CVE-2015-1828/ 和 https://github.com/rubysec/ruby-advisory-db/blob/master/gems/http/CVE-2015-1828.yml 中被提及已修复，但在原始供应商披露（https://groups.google.com/g/httprb/c/jkb4oxwZjkU 年）或 ruby/openssl#8 0.6.4 中完全没有提及。你是怎么确定 0.6.4 包含补丁的？

Thanks for raising this — the reason I concluded that 0.6.4 contains the fix is not from the original disclosure email alone, but from the actual 0.6.3 -> 0.6.4 package diff and changelog for the http gem.

Specifically, the 0.6.4 release contains all of the indicators we would expect for a genuine backport of CVE-2015-1828:

1. The 0.6.4 changelog explicitly calls out CVE-2015-1828 as a security fix
   In the published gem diff, CHANGES.md for 0.6.4 includes a security entry stating that:

   • http.rb failed to call #post_connection_check
   • this made it vulnerable to MitM attacks
   • the issue was corrected by calling #post_connection_check
   • it references CVE-2015-1828
   • and it explicitly says the fix was backported by @nicoolas25

2. The actual TLS verification code was backported into the 0.6.x line
   In the 0.6.3 -> 0.6.4 diff for lib/http/client.rb, the code was changed to pass the hostname into the TLS setup and call:

   • socket.post_connection_check(host)
     when verify_mode == OpenSSL::SSL::VERIFY_PEER

   That is the exact remediation described in the original disclosure.

3. A regression test was added
   The 0.6.4 diff also adds a regression test in spec/http/client_spec.rb asserting that a hostname mismatch raises OpenSSL::SSL::SSLError, which is strong evidence that hostname verification was intentionally fixed in that release.

The best supporting source for this is the published gem diff here:

• https://my.diffend.io/gems/http/0.6.3/0.6.4

RubySec and the Ruby Advisory DB are consistent with that package-level evidence and list the patched version lines as:

• >= 0.7.3
• ~> 0.6.4

References:

• RubySec advisory: https://rubysec.com/advisories/CVE-2015-1828/
• Ruby Advisory DB: https://github.com/rubysec/ruby-advisory-db/blob/master/gems/http/CVE-2015-1828.yml

So to clarify the reasoning:

• the original vendor disclosure establishes the vulnerability and the mainline fix at 0.7.3
• the 0.6.3 -> 0.6.4 gem diff provides the evidence that the same fix was backported to the 0.6.x maintenance line
• RubySec then reflects that backport in its normalized advisory metadata

That is why I suggested the affected ranges should be modeled as:

• < 0.6.4
• >= 0.7.0, < 0.7.3

rather than simply < 0.7.3.

Hi @tjuyuxinzhang! Thank you so much for contributing to the GitHub Advisory Database. This database is free, open, and accessible to all, and it's people like you who make it great. Thanks for choosing to help others. We hope you send in more contributions in the future!